Enterprise computing systems typically include one or more host systems for processing customer data and running application programs, direct access storage devices (DASDs) for storing the data, and one or more storage controllers for directing the storage and retrieval of data between the host(s) and the DASDs. In addition to the customer data, the storage controller typically maintains metadata which provides information about tracks or blocks of data in the DASD or in cache storage in the storage controller. The storage controller processes the metadata during certain operations on the customer data represented by the metadata to improve the speed and efficiency with which requested operations are performed. During DASD initialization, metadata is staged from disk to a cache storage (a volatile type of storage). A power failure or certain other types of errors may cause the contents of the cache to be lost.
Certain storage controllers, such as the IBM™ Enterprise Storage Server™ (ESS), may be configured with copy services functionality, including (but not limited to) flash copy, peer-to-peer remote copy, extended remote copy, and concurrent copy which assist in backing up data and recovering from disasters. During a copy service (CS) operation, multi-field CS metadata is generated and maintained by the storage controller. The CS metadata includes information about the state of a copy services operation at any point in time, such as internal settings, source and destination addresses, and other data about the state of data being copied. Consequently, if a controller loses power or encounters some other interrupting event, the controller may be restarted, the metadata read, the CS operation restored to the point of interruption and then resumed and completed.
In an earlier version of the IBM ESS, the CS metadata was maintained in a 26 KB in-memory structure that was updated directly by the clients. During an update, the entire structure was written to disk, even if only a few fields were updated, and no record was kept of which fields of the metadata were changed. In a subsequent version, the 26 KB structure of CS control data was mapped to seven 8 KB global metadata tracks. During an update, only a metadata track containing an updated field was written to the disk. While an improvement over the original process, there was still no record of which fields were updated. When the 8 KB track is written to disk, the track is divided into three parts, and each part is a single write operation. For security, each full 8 KB track is stored in three separate locations. Therefore, each update to a single metadata track requires nine write operations.
Journaling has been implemented to allow storing updates in non-volatile storage (NVS), improving update performance and maintaining the metadata in the event of a power loss or other significant event. Each metadata track has a corresponding page in NVS which includes a chain of blocks containing a sequence of journal entries identifying an operation being performed and the data in cache being modified. During a recovery operation, the metadata may be staged from disk to cache and the changes previously recorded in the journal entries applied, thereby restoring the metadata to have the most current version of data. Nonetheless, the fields which have been modified may not be specifically identifiable. Additionally, as is known NVS is expensive relative to other types of storage and, therefore, it is desirable to limit its use as much as possible.
In such prior systems, when a client requested access to a metadata track, such as to update one or more fields in the track, numerous controller resources are required to provide such functions as journal access, track access, task control block (TCB) allocation and track lock (to ensure that only one process has access to target data at a time). Such resource use ties up the controller processor. Furthermore, heretofore the client has had full access to the metadata tracks, subjecting them to possible overwrites and other risks to integrity. A metadata track may also become invalid for any of a number of reasons, such as a memory overwrite, a failover/power loss, or a bad longitudinal redundancy check (LRC). For example, during error handling recoveries, the LRC is checked and, if not correct, the track is marked as invalid. It will be appreciated that an attempt to access or update an invalid metadata should not be made.
Consequently, it remains desirable for more efficient and thorough management of metadata, such as copy services metadata.